The Internet Engineering Task Force (IETF) has standardized the IPSEC (Internet Protocol Security) protocol suite; the standards are well known from the Request For Comments or RFC documents number RFC2401, RFC2402, RFC2406, RFC2407, RFC2408 and RFC2409 mentioned in the appended list of references, all of which are hereby incorporated by reference. The IPSEC protocols provide security for the IP or Internet Protocol, which itself has been specified in the RFC document number RFC791. IPSEC performs authentication and encryption on packet level by generating a new IP header, adding an Authentication Header (AH) or Encapsulating Security Payload (ESP) header in front of the packet. The original packet is cryptographically authenticated and optionally encrypted. The method used to authenticate and possibly encrypt a packet is identified by a security parameter index (SPI) value stored in the AH and ESP headers. The RFC document number RFC2401 specifies a transport mode and a tunnelling mode for packets; the present invention is applicable regardless of which of these modes is used.
In recent years, more and more vendors and Internet service providers have started performing network address translation (NAT). References to NAT are found at least in the RFC document number RFC1631 as well as the documents which are identified in the appended list of references as Srisuresh98Terminology, SrisureshEgevang98, Srisuresh98Security, HoldregeSrisuresh99, TYS99, Rekhter99, LoBorella99 and BorellaLo99. There are two main forms of address translation, illustrated schematically in FIGS. 1a and 1b: host NAT 101 and port NAT 151. Host NAT 101 only translates the IP addresses in an incoming packet 102 so that an outgoing packet 103 has a different IP address. Port NAT 151 also touches the TCP and UDP port numbers (Traffic Control Protocol; User Datagram Protocol) in an incoming packet 152, multiplexing several IP addresses to a single IP address in an outgoing packet 153 and correspondingly demultiplexing a single IP address into several IP addresses for packets travelling in the opposite direction (not shown). Port NATs are especially common in the home and small office environment. The physical separation of input and output connections for the NAT devices is only shown in FIGS. 1a and 1b for graphical clarity; in practice there are many possible ways for physically connecting a NAT.
Address translation is most frequently performed at the edge of a local network (i.e., translation between multiple local private addresses on one hand and fewer globally routable public addresses on the other). Most often, port NAT is used and there is only one globally routable address. A local network 154 has been schematically illustrated in FIG. 1b. Such arrangements are becoming extremely commonplace in the home and small office markets. Some Internet service providers have also started giving private addresses to their customers, and perform address translation in their core networks for such addresses. In general, network address translation has been widely discussed in depth e.g. in the NAT working group within the Internet Engineering Task Force. The operating principles of a NAT device are well known, and there are many implementations available on the market from multiple vendors, including several implementations in freely available source code. The typical operation of a NAT may be described so that it maps IP address and port combinations to different IP address and port combinations. The mapping will remain constant for the duration of a network connection, but may change (slowly) with time. In practice, the NAT functionality is often integrated into a firewall or a router.
FIG. 1c illustrates an exemplary practical network communication situation where a transmitting node 181 is located in a first local area network (also known as the first private network) 182, which has a port NAT 183 to connect it to a wide-area general packet-switched network 184 like the Internet. The latter consists of a very large number of nodes interconnected in an arbitrary way. A receiving node 185 is located in a second local area network 186 which is again coupled to the wide-area network through a NAT 187. The denominations “transmitting node” and “receiving node” are somewhat misleading, since the communication required to set up network security services is bidirectional. The transmitting node is the one that initiates the communication. Also the terms “Initiator” and “Responder” are used for the transmitting node and the receiving node respectively.
The purpose of FIG. 1c is to emphasize the fact that the communicating nodes are aware of neither the number or nature of the intermediate devices through which they communicate nor the nature of transformations that take place. In addition to NATs, there are other types of devices on the Internet that may legally modify packets as they are transmitted. A typical example is a protocol converter, whose main job is to convert the packet to a different protocol without disturbing normal operation. Using them leads to problems very similar to the NAT case. A fairly simple but important example is converting between IPv4 and IPv6, which are different versions of the Internet Protocol. Such converters will be extremely important and commonplace in the near future. A packet may undergo several conversions of this type during its travel, and it is possible that the endpoints of the communication actually use a different protocol. Like NAT, protocol conversion is often performed in routers and firewalls.
It is well known in the IPSEC community that the IPSEC protocol does not work well across network address translations. The problem has been discussed at least in the references given as HoldregeSrisuresh99 and Rekhter99.
In the Finnish patent application number 974665 and the corresponding PCT application number FI98/01032, which are incorporated herein by reference, we have presented a certain method for performing IPSEC address translations and a method for packet authentication that is insensitive to address transformations and protocol conversions en route of the packet. Additionally in said applications we have presented a transmitting network device and a receiving network device that are able to take advantage of the aforementioned method. However, some problems related to the provision of network security services over network address translation remain unsolved in said previous patent applications.